AWS Database Migration Serviceを使ったデータ移行手順まとめ(MySQLからAurora編)
西澤です。MySQLからAurora(または別環境のMySQL)へのデータ移行を行う場合、mysqldumpを利用したフルバックアップ、リストアで進めるのが一般的かと思いますが、データベース切替に伴うサービスダウンタイムを極力短くしたいというケースは非常に多いと思います。特にデータ量が多い場合、システム移行に要する時間は、ほぼデータ移行に要する時間で決まると言っても過言ではありません。この煩わしい作業を簡単に行えるようにしてくれるサービスがDMSです。今回MySQLからAurora(移行先はMySQLでもほぼ作業は同じはず)へのデータ移行を、DMSを使って行う機会があったので手順をまとめておきたいと思います。
DMSって何？という方は、まず下記記事をご覧ください。
- AWS Database Migration Serviceを試してみた ｜ Developers.IO
- 【新機能】AWS DMSでMulti-AZと継続的レプリケーションをサポートしました ｜ Developers.IO
1. 事前準備
まずは、事前準備のポイントについて整理しておきます。DMSレプリケーションインスタンスを構築する作業や、レプリケーションタスクを実行すること自体は、全てAWS Management Consoleから行うことができ、非常に簡単です。それだからこそ、移行計画に当たっては、事前準備と移行検証が最も重要です。
通信経路の確保
DMSレプリケーションインスタンスから、ソースエンドポイント、ターゲットエンドポイントへデータベースが利用するポートで疎通できるようにしておくことがまずは大前提となります。
SQLクライアント環境の準備
DMSは決して万能ではありません。結局、移行データの確認やデータの修正作業等のSQL実行が、必ず必要となります。ソースDBおよびターゲットDBにアクセス可能なSQLクライアント環境を用意しておきましょう。
ソースDB(MySQL)側の前提作業
サポートされている各DBエンジン別に細かくドキュメントが公開されていますので、必ず全てに目を通し、前提がクリアできているか確認しましょう。今回のケースでは、ソースDBがオンプレ環境のMySQLで、CDC(Change Data Capture)も利用した為、下記設定が必要でした。
| Parameter | Value |
|---|---|
| server_id | 1以上 |
| log-bin | Set the path to the binary log file |
| binlog_format | row |
| expire_logs_days | 1以上 |
| binlog_checksum | none |
| binlog_row_image | full |
ターゲットDB(Aurora)側の前提作業
こちらも同様にDBエンジン別にドキュメントが用意されていますので、目を通すことには変わりありません。ただ、今回のケースでは移行先のデータベースはこれから作成するものなので、新規に用意したRDSインスタンスに管理者ユーザで接続することにしました。ターゲットDBがAurora(またはMySQL)の場合、下記設定をターゲットエンドポイントのExtra Connection Attributesに設定しておくことで、外部キー制約を無視する形でデータ移行を行うことができます。後にも触れますが、今回のケースではこの設定が非常に有効でした。
initstmt=SET FOREIGN_KEY_CHECKS=0
2. スキーマ移行
DMSではビューや制約等を全て移行してくれるわけではありません。基本的には、移行してくれるのはデータと主キーと考えても問題ありません。その為、テーブル定義等の情報は別の手段で移行する必要があります。
mysqldumpを利用したスキーマ移行
ということで、今回はmysqldumpコマンドの--no-data, -dオプションを利用して、テーブル定義情報を事前に移行する形を取ることにしました。この方法では、事前に外部キー制約等も移行されますが、ターゲットエンドポイントに設定した前述のオプション追加により、DMSによるデータ移行を問題なく行うことができることがわかりました。
- ソースDBに接続して実行
$ mysqldump -h ${SRCDBHOST} -u ${SRCDBUSER} -p --no-data [SCHEMA_NAME] > DUMP.sql
- ターゲットDBに接続して実行
$ mysql -h ${DSTDBHOST} -u ${DSTDBUSER} -p < DUMP.sql
必要に応じて、--routines, -Rオプションも利用すれば、stored routines (procedures and functions)の移行も可能なようですが、今回試したケースでは必要ありませんでした。
DEFINER指定のVIEWやストアドプログラムに注意
今回ユーザ移行は別途行う方針とした為、ターゲットDBであるRDS側では、rdsadminと指定した管理者ユーザ以外は存在しない状態でした。そこで、今回のデータ移行では、DEFINER属性があったものは全てCURRENT_USERで一旦移行する方針としました。その為、実際には前述のmysqldumpコマンドによって生成されたSQLを手作業で修正しました。
3. DMSレプリケーションタスク実行
それではいよいよデータ移行をやってみます。
DMSレプリケーションタスク作成
今回は、初回転送に加えて差分転送も行うオプションで実行します。
Task Settingsの"Target table preparation mode"は、必ず"Do nothing"または"Truncate"を選択しておきましょう。誤って"Drop tables on target"を選択してしまうと、せっかく事前に移行したテーブル定義情報が削除されてしまいます。また、問題が発生したときの為に、必ず"Enable logging"にはチェックを入れて、ロギングを有効にしておきましょう。
今回はスキーマ名(データベース名)の変更を行う必要がありましたので、Table mappings設定で"Custom"を選択しました。
Table mappings設定については、下記ドキュメントに具体的なサンプルとともに詳しく記載されていますので参考にしてください。
Using Table Mapping with an AWS Database Migration Service Task - AWS Database Migration Service
レプリケーションタスクの実行結果
上手く行きました。初回移行されたデータに続けて、差分データも順次移行されているようです。これでいつでもシステム移行が開始できますね。
同期状態は、レプリケーションインスタンス上に保持される仕様とのことなので、継続的に利用する場合には必ずMulti-AZにしておきましょう。
注意事項
注意事項を、2016/09/05(月)に追記しました。
注意事項1: CDCをサポートする型
ENUM型、SET型のカラムは、差分転送=change data capture(CDC)されないことがわかり、残念ながら今回利用したケースでは"Full load"1回でのデータ移行方式となってしまいました。こちらも公式ドキュメントには記載されていたので、十分に目を通しておけばもっと早めに気付くことができた問題だと思います。
- AWS Developer Forums: MySQL to MySQL replication - ENUM and ...
- Source Data Types for MySQL - AWS Database Migration Service
注意事項2: ログに記録される警告
CDCを利用した転送を行っていると、下記のような警告がレプリケーションタスクのログに記録されることがありました。
2016-xx-xxTxx:xx:xx [TARGET_APPLY ]W: Some changes from the source database had no impact when applied to the target database. See 'awsdms_apply_exceptions' table for details. (endpointshell.c:3456)
このログについては公式ドキュメントに記載がありました。awsdms_apply_exceptionsテーブルに記録されたログも確認したのですが、MySQLでは同一のVALUEのままUPDATE文を実行すると、"0 rows affected warning"が出力されることが原因ということで、これは無視して問題無いものと判断しました。
In addition, when you update a column's value to its existing value, MySQL returns a 0 rows affected warning. In contrast, Oracle performs an update of one row in this case. The MySQL result generates an entry in the attrep_apply_exceptions control table and the following warning:
Some changes from the source database had no impact when applied to the target database. See attrep_apply_exceptions table for details.
まとめ
他にもより簡単で効率的な方法があるかもしれませんが、MySQL系DBのデータ移行作業でDMSを利用する際のベースとなる手順をようやく1つまとめることができました。実際にはかなり試行錯誤しているのですが、とにかく公式ドキュメント(まだ全て英語ですが)をよく読んで準備、計画していただくことをお勧めします。また、実際のデータ移行の際には、アプリケーション側からも十分にテストを行い、必要なユーザ等、移行漏れが無いか十分に確認をして進めてください。
どこかの誰かのお役に立てば嬉しいです。
